I. INTRODUCTION:

Computers play an increasingly larger role in everyday life. From the embedded microprocessors found in virtually every electronic appliance, to the escalating number of personal computers used for business, entertainment and education, Nicholas Negroponte’s statement that “computing is not about computers… it is about living”1 is becoming truer by the day¹. Now, with the recent explosive growth of the Internet, all these computers are becoming interconnected in a global communications network. Many view the Internet as a universal communications medium that can replace telephone, television and radio. The potential is there, but progress has been hampered by the open design of the network itself. It is still too easy to intercept, monitor and forge messages on the Internet, and people are reluctant to use the network for financially or legally sensitive data. The problems faced by users of the Internet fall into two main categories: privacy and authentication. Privacy involves transmitting messages that cannot be altered or read en route, while authentication allows each party to a communication to be sure of the identity of the other (i.e. messages can’t be forged).

Cryptography holds the promise of a solution to these problems. Cryptography is the science of secret writing. It provides a means whereby two people (or their computers), commonly designated Alice and Bob, can communicate openly in such a way that a third party, usually named Oscar, is unable to determine or alter what is being said. By assuring privacy, cryptography indirectly provides authentication because only Alice and Bob know how to encrypt and decipher each other’s messages. A form of cryptography known as public-key cryptography appears to be best suited to fulfilling the requirements of the Internet². Each user of a public-key cryptosystem holds a pair of related keys. Anything encoded with one key can only be decoded by it’s counterpart. Each user keeps one key secret and publishes the other. Thus other people can employ the user’s public key to send messages that only the user can read, or the user can “sign” a message with her private key to authenticate it – other people can apply the user’s public key to verify that the message came from the user. Crucial to the operation of a global public-key cryptosystem on the Internet is a practical and reliable means of publishing the public keys, called a Public-Key Infrastructure or PKI. There are as yet only a handful proposals for an Internet PKI, 2 many of which are still in draft form, and no single one has yet to gain widespread use on the network. Indeed, many feel that, for the near future, there will be several PKI systems operating and inter-operating on the Internet³.

II. PKI CRYPTOGRAPHY BASICS:

Secret-Key Cryptography:

Secret-key cryptography 3 is the classical form of cryptography that has been around since ancient times. With a secret-key cryptosystem, Alice and Bob share a secret: the key used for encryption and decryption. This requires prior communication between Alice and Bob over a secure channel, so that they may agree on a key. There are a great many secret-key systems, the best-known probably being the Data Encryption Standard (DES, and it’s newer counterpart Triple-DES) [DES].

There exist systems for communicating securely over public networks using only secret-key cryptography, most notably MIT’s Kerberos system ([RFC1510]). However, these schemes do not scale well to large, inter-organizational populations, and they also carry extra security procedures that public-key systems do not need, such as storing the secret keys on a secure, central server. Still, as we shall see below, secret-key systems have their place in a PKI⁴.

Figure 1 – Message encryption using a secret key (S) to encode the message and a public key (P) to encode the secret key

Public-Key Cryptography:

In contrast with secret-key cryptography, public-key cryptography is very new. It was first conceived in 1976 by Diffie and Hellman ([DH76]), and in 1977 Rivest, Shamir and Adleman invented the RSA Cryptosystem ([RSA78]), the first realization of a public-key system. There have since been several proposals for publickey schemes, including the ElGamal Cryptosystem ([El85]) and elliptic curve cryptosystems ([Sa96]). Each public-key cryptosystem has its own technical nuances, however they all share the same basic property that given an encryption key it is computationally infeasible to determine the decryption key (and vice-versa). This property lets a user, Alice, publish her encryption key. Anyone can use that public key to encrypt a message that only Alice can decipher with her private key⁵. We say that Alice “owns” the “key-pair.” In practice, computing a public-key cipher takes much longer than encoding the same message with a secret-key system.4 This has lead to the practice of encrypting messages with a secret-key system such as DES, then encoding the secret key itself with a public-key system such as RSA (see Figure 1). We say that the public-key system “transports” the secret key. Since the secret key is usually much shorter than the message, this technique results in significantly faster processing than if public-key cryptography alone were used. Thus each securely-transmitted message has two components: the message proper (encoded with a secret-key system) and the key used to encode the message (itself encoded using a public-key system)⁶. Reading the message is hence a two step process: first decode the secret key, then decode the message.

Digital Signatures:

The very nature of public-key cryptography permits a form of message signing. Suppose Alice publishes her decryption key and keeps her encryption key secret. When Alice encrypts a message, anyone can decrypt it using her public decrypting key and, in doing so, they can be sure that the message could only have been encrypted by Alice, since she is the sole possessor of her encryption key. Alice has effectively “signed” the message. Some public-key cryptosystems, such as RSA, have the property that both the public and private keys can be used for encryption and decryption. In other words, one key pair can be used for both message encryption and digital signature. This practice, however, creates a number of problems with respect to the management of the key pair⁷. For example, consider the archival requirements of the private key under each circumstance. For a key pair used for digital signatures, the private key should never be backed up, and it should be destroyed at the end of its active life. If the private key is ever disclosed it can be used to forge documents. Even if its value is discovered long after its active life has ended, it can still be used to forge signatures on ostensibly-old documents. In contrast, with a key pair used for encryption the private key should be archived for as long as possible, because if the private key is ever lost it would be impossible to retrieve messages encrypted with its public counterpart. It is therefore sensible to keep multiple copies of this private key⁸. Since this contradicts the archiving requirements of a signature private key, one is better off in keeping separate key pairs for each function. [FoBa] discusses these issues in greater depth. For our purposes, we will always assume that the encrypting key pair is distinct from the signature key pair.

Hash Functions:

Typically, to digitally sign a message, rather than encrypt the message using a publickey scheme, the message is hashed using a cryptographic hash function, and the hash is encrypted. A cryptographic hash function maps an arbitrary-length message to a fixed number of bits. Hash functions have the following properties⁹: ·

They are collision-free: it is computationally infeasible to find two different messages that have the same hash.

They are one-way: given a message hash, it is computationally infeasible to find any message with the same hash value.

The first property in fact implies the second; we list both to better illustrate the concept. Hash functions are also called message digest or fingerprint algorithms.

Some better-known examples are MD5 ([RFC1321]) and SHA-1 ([SHS]). As we stated above, digitally signing a message using hashes is a two-step process. The message is first hashed, then the hash result is encrypted using a public-key scheme. Then the message is transmitted along with its encrypted hash. To verify the signature, the recipient needs to hash the message himself, then decrypt the transmitted hash and compare the pair of hash values. The signature is valid if the two values match, otherwise the message was somehow altered, perhaps maliciously, in transit

Figure 3 – Basic public-key cryptography message formats

III. BASIC PUBLIC-KEY INFRASTRUCTURE:

CHARACTERISTICS:

What is a Public-Key Infrastructure?

In its most simple form, a PKI is a system for publishing the public-key values used in public-key cryptography. There are two basic operations common to all PKIs:

· Certification is the process of binding a public-key value to an individual, organization or other entity, or even to some other piece of information, such as a permission or credential.

· Validation is the process of verifying that a certification is still valid. How these two operations are implemented is the basic defining characteristic of all PKIs.

We now describe in general terms the various methods employed to perform these operations, and discuss the various issues that result from their use. As we proceed, we will point out the basic characteristics of PKIs.

Certification:

Certification is the fundamental function of all PKIs. It is the means by which public-key values, and information pertaining to those values, are published. For our purposes, we define a certificate as the form in which a PKI communicates public key values or information about public keys, or both¹⁰.

This is a very broad definition of a certificate. At its most basic, a certificate is merely a public key value. In more traditional terms, a certificate is a collection of information that has been digitally signed by its issuer (see Figure 4). Such certificates are distinguished by the kind of information they contain. An identity certificate simply identifies an entity, called the certificate subject, and lists the public-key value(s) for that entity.6 A credential certificate describes non-entities, such as a permission or credential. This is discussed further below under Authentication.

Figure 4 – A basic certificate

A certificate user is an entity who relies upon the information contained in a certificate. The certificate user trusts the issuing authority to issue “true” certificates. That is, certificates which truly identify the subject and its public key (in the case of identity certificates), or which truly describe a subject’s credentials (in the case of credential certificates). The certificate issuer is commonly called a certification authority (CA). To help illustrate these concepts, we present an example using identity certificates. Imagine that Alice wishes to securely communicate with Bob using a public key cryptosystem. Alice needs to know the value of Bob’s public encrypting key. Without a PKI, Alice must have direct knowledge of that key, i.e. Bob must com- municate it to her via a secure channel. If Alice also wishes to communicate with Doug, she must also have direct knowledge of Doug’s public encrypting key. With a PKI, Alice only needs to have direct knowledge of a CA’s public signing key. The CA would issue an identity certificate for each of Bob’s and Doug’s public encrypting keys. Then if Alice wishes to communicate with Bob or Doug, she can use the appropriate certificate to obtain the correct public key value. In this case, Alice is the certificate user while Bob and Doug are both the subjects of different certificates. The information contained in a certificate is a basic characteristic of different PKIs. As well, the relationship between the CA, the certificate user and the certificate subject forms another basic PKI characteristic. All three may be distinct entities, such as in the above example, or any two (or all three) can be the same entity. The trust relationships between the three also form a third basic PKI characteristic. In the above example, Alice is required to trust the CA’s certificates. If Alice and the CA are distinct entities, how Alice trusts the CA will define how much confidence she has in using the CA’s certificates for secure communications.

CA Arrangements:¹¹

It is obviously impractical to have a single CA act as the authority for the entire world. Therefore, most PKIs permit CAs to certify other CAs. In effect one CA is telling its users that they can trust what a second CA says in its certificates. Returning to our example above, Alice, Bob and Doug would typically each be certified by a different CA¹². For Alice to then communicate with Bob, she would either need direct knowledge of Bob’s CA’s signature public key, or Alice’s CA could issue a certificate for that key. Then Alice could securely obtain Bob’s public key while only having direct knowledge of her CA’s key. In this case, the certificates issued for Alice and Bob are called end-user certificates while the certificate issued by Alice’s CA for Bob’s CA is called a CA-certificate. In general, there may be an arbitrary number of CAs on a path between Alice and Bob (see Figure 5). To obtain Bob’s public key, Alice would have to verify the certificate of each CA in turn until she obtained Bob’s certificate.

Figure 5 – A certification path from Alice to Bob

This process is called certification path validation. The length of the certification path is the number of CAs between Alice and Bob, or the number of certificates Alice needs to verify in obtaining Bob’s key. two CA-certificates and one end-user certificate. Certificate 1 is a CA-certificate issued by CA X for CA Y. CA Y issued CA-certificate 2 for CA Z, which has issued an end-user certificate for Bob’s key (certificate 3)¹³.

When Alice validates the certification path, she starts with CA X’s public key, which she uses to validate certificate 1. Then she uses the public key for CA Y she obtained from certificate 1 to validate certificate 2, thus acquiring CA Z’s public key, which she can then use to validate certificate 3 and securely obtain Bob’s public key.

How the CAs of a PKI are arranged is a basic PKI characteristic. Some PKIs use a general hierarchy,

IV. PROPOSED METHODOLOGY:

1. Encrypt the data using a Symmetric Key(call Symmetric-Encrypt)

2. 2. Encrypt the Symmetric key using the Receivers public key

3. Store a public key in the set of public key.

4. Create a Message Digest of the data to be transmitted

5. Sign the message to be transmitted using digital signature

6. Send the data over to an unsecured channel

7. Validate the Signature using certificate authority

8. Decrypt the message using Receivers public key from the set of key to get the Symmetric Key. (Call Import-key and Test Key pair)

9. Decrypt the data using the Symmetric Key

10. Compute Message-Digest of data + Signed message

11. Validate if the Message Digest of the Decrypted Text matches the Message Digest of the Original Message

Symmetric-Encrypt

1. Generate a DES key (specify the Key size during this phase)

2. Create the Cipher

3. To Encrypt : Initialize the Cipher for Encryption

4. To Decrypt : Initialize the Cipher for Decryption

Import-key

1. Receive a certificate

2. Validate the certificate

3. Provide a authorize key to user

Test-Key-Pair

1. Receive a key from import key

2. Test the key against the user

3. If true

4. Return

5. Else

6. False

V. CONCLUSION:

In this paper , we have presented alternative PKI trust models to the current web model used in Minisip, with a focus on the top-down model¹⁴. The implementation provides authentication of SIP users by using the user’s SIP ID as the common name in the certificate. In the namespace, every name is mapping to a unique CA or end-user. Along with the rigid hierarchical namespace, the CA’s right to issue certificates has been limited. This reduces the security risk of the web model, and meets the initial goal of the thesis. In order to make the top-down model easy to deploy, we made a policy that allows setting multiple trust anchors except for the root. Due to the name subordination policy, setting more trust anchors would not decrease the security in the entire PKI. By supporting the CRL checking, the implementation is straightforward to the deployment of the up-cross-down and the bridge CA models. Certificate and CRL caching can greatly decrease the workload of downloading certificates and CRLs and certificate signature validation. The update of cache ideally ensures the availability of the cached certificates and CRLs, also secures the accuracyof certificate validation¹⁵.

REFERENCES:

1. J. Rosenberg et al, “SIP: Session Initiation Protocol”, RFC 3261, Jun. 2002

2. J.Arkko et al, “MIKEY: Multimedia Internet KEYing”, RFC 3830, Aug. 2004

3. M.Baugher et al, “The Secure Real-time Transport Protocol”, RFC 3711, Mar. 2004

4. H. Schulzrinne et al, “RTP: A Transport Protocol for RealTime Applications”, RFC 3550, Jul. 2003

5. R. Stewart et al, “Stream Control Transmission Protocol”, RFC 2960, Oct, 2000

6. R. Housley et al, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”, RFC 3280, Apr. 2002

7. M. Wahl et al, “Lightweight Directory Access Protocol (v3)”, RFC 2251, Dec. 1997

8. R. Perlman, “An Overview of PKI Trust Models”, IEEE, Dec.1999

9. John Linn, “Trust Models Management in Public Key Infrastructures”, Nov. 2000

10. R. Arends et al, “DNS Security Introduction and Requirements”, RFC 4033, Mar. 2005

11. M.Myers, et al, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”, RFC 2560, June 1999

12. T. Freeman, et al, “Standard Certificate Validation Protocol (SCVP)”, Internet Draft, Mar. 2006

13. C. Neuman, “The Kerberos Network Authentication Service (V5)”, RFC 4120, Jul. 2005

14. J. Bilien, “Key Agreement for Secure Voice over IP”, Master Thesis, KTH, Stockholm, Dec. 2003

15. J. Orrblad, “Alternative to MIKEY/SRTP to secure VoIP”, Master Thesis, KTH, Stockholm, Mar. 2005

Received on 08.11.2011 Accepted on 14.11.2011

Int. J. Tech. 1(2): July-Dec. 2011; Page 112-116